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Abstract 

The  Common  Time  Module  (CTM)  is  being  developed  by  Symmetricom  with  support  from 
the  US  Army/CERDEC.  The  goal  is  to  implement  timing  services  for  mobile  systems  that 
demand  a  high  degree  of  reliability  and  precision.  The  system  is  based  around  a  core  module 
that  implements  a  time  and  frequency  server  with  provisions  for  legacy  time  protocols.  To 
address  the  rigors  of  a  mobile  and  dynamic  environment,  the  CTM  manages  multiple 
connections  to  the  common  time  reference  (UTC-USNO).  Either  GNSS  signals  (GPS)  or  a 
network  connection  ( IEEE-1588 )  can  synchronize  local  time  services.  In  addition,  the  CTM 
integrates  a  low-power  atomic  resonator  for  extended  holdover  capabilities.  By  dynamically 
managing  these  technologies,  the  CTM  can  supply  accurate  time  and  frequency  in  a  wide  range 
of  deployment  scenarios.  Furthermore,  improvements  in  low-power  technology  such  as  Chip- 
Scale-Atomic-Clock  (CSAC)  will  dramatically  reduce  power  requirement,  which  is  a  significant 
advantage  to  mobile  systems.  Finally,  this  paper  will  examine  how  standardized  IEEE-1588 
network  techniques  will  be  applied  to  support  redundancy  with  the  CTM. 


1  INTRODUCTION:  WHAT  IS  THE  CTM? 

Common  Time  Module  (CTM)  is  a  development  program  investigating  techniques  for  implementing 
accurate  timing  resources  on  mobile  platforms.  It  is  being  developed  by  Symmetricom  and  managed  by 
CERDEC  Command  and  Control  Directorate  (C2D)  under  contract  #  WP15P7T-08-C-V205.  CTM  is  a 
three-phase  program  and  is  nearing  the  end  of  Phase  II.  Although  the  program  goals  include  a  system¬ 
centric  view  of  mobile  platforms,  this  is  not  uniquely  a  paper  study.  The  program  is  developing  a 
prototype  time  server  module  that  forms  the  backbone  of  the  proposed  architecture.  This  module  is  also 
referred  to  as  the  CTM. 

The  goal  of  the  program  is  to  develop  a  core  timing  capability  that  can  be  used  on  multiple  platforms  and 
deployment  architectures.  Baseline  program  goals  call  for  a  high  level  of  timing  performance  married  to 
system  goals  of  robustness,  reliability,  and  scalability.  To  demonstrate  this  capability,  Symmetricom  is 
developing  a  time  server  module  testbed  for  Phase  II  of  the  contract.  Using  lessons  learned  during  Phase 
II,  a  prototype  module  will  be  demonstrated  in  Phase  III. 


2  DEPLOYMENT  ENVIRONMENTS 

CTM  is  designed  to  support  mobile  platforms  such  as  the  examples  listed  in  Error!  Reference  source 
not  found..  The  target  space  would  have  a  limited  number  of  time  clients  and  it  is  not  expected  to 
support  wide-area  networking.  These  systems  are  centrally  defined  and  controlled.  Therefore,  we  can 
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assume  some  level  of  coordination  in  the  system  definition.  This  has  the  advantage  of  avoiding  issues 
associated  with  open-network  elements  that  can  adversely  impact  the  overall  system  timing  performance. 
However,  application  of  industry  standard  techniques  and  COTS  methodology  is  a  requirement  for 
interoperability  and  system  maintenance  and  low  life-cycle  cost.  The  program  must  leveraging  industry 
standard  techniques  and  protocols  with  mitigation  strategies  to  maintain  the  desired  performance  levels  in 
a  military  environment. 


Table  1.  CTM  Candidate  Platforms. 


Platforms 

Infantry  Carrier  Vehicle 

Command  and  Control 
Vehicle 

Warfighter  (eventually) 

#L\  \lfcw 

/ 

1  1  l 

SL 

f.  |  • 

Relative  System 
Size 

Medium-small 

Medium 

Small 

Unique 

Requirements 

Legacy  Support, 
Holdover  time 

Legacy  Support, 
Redundancy 

Holdover  Capability, 
Lowest  Power 

Typical 

Configuration 

Single  CTM,  small 
network 

Dual  CTM,  redundancy 

Single  CTM,  no  network 

3  PROGRAM  GOALS 

With  the  target  environment  defined,  the  next  step  is  to  consider  the  program  goals  in  more  detail  and 
define  the  CTM  approach  to  meeting  these  requirements. 

3.1  Central  Time  Service 

Robust  and  accurate  time  is  frequently  a  requirement  for  instrument  packages  in  modem  mobile 
platforms.  In  many  programs,  time  maintenance  requirements  are  dispersed  among  different  instrument 
packages  and  vendors,  which  can  create  unnecessary  duplication  of  functionality.  This  approach  can 
drive  up  power  (and  cooling)  requirements  on  the  final  system.  Frequently,  the  resulting  duplication  of 
timing  equipment  provides  no  effective  redundancy  and  overall  timing  reliability  is  suboptimum.  The 
CTM  will  address  the  somewhat  conflicting  goals  of  reduced  system  power,  while  providing  capabilities 
for  redundancy  and  fault  tolerance. 

3.2  Robust  and  Reliable  Time 

As  discussed  above,  a  central  time  server  provides  key  advantages.  However,  an  equally  important  goal 
of  this  program  is  to  identify  ways  to  improve  system  reliability  and  robustness.  Naturally,  a  centralized 
resource  is,  in  effect,  a  single -point  of  failure  and  tends  to  diminish  this  attribute.  To  achieve  both  goals, 
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CTM  can  serve  as  a  Master  Clock  in  a  distributed,  network-centric  implementation.  This  allows  the 
CTM  to  leverage  a  large  number  of  industry  standard  techniques  for  fault  tolerance  and  redundancy. 
Such  properties  are  easy  to  implement  in  Ethernet-based  networks,  which  are  designed  for  fault  tolerance. 
Overall,  it  has  been  our  conclusion  that  network-based  time  distribution  is  the  best  approach  to  achieving 
this  goal. 

3.3  Scalability 


Figure  1  shows  a  simple  non-networked  application  of  the  CTM.  In  this  implementation  topology,  the 
CTM  supplements  GPS  time  with  a  disciplined  rubidium  (Rb)  oscillator  holdover  feature.  Time  is 
available  to  users  via  a  legacy  port,  such  as  AN/PSN-1 1  TOD  or  PPS.  This  CTM  topology  can  support 
small  platforms,  including  a  near-term  goal  of  extending  this  capability  to  instrument  packages  carried  by 
individuals  (warfighter). 


GPS  Ant 


Network 

Port 


Figure  1.  Simple  CTM  system  deployment. 


Beyond  the  minimal  system  described  above,  the  CTM  implements  networking  to  support  more  complex 
platforms.  This  paper  will  explore  how  networking  is  the  essential  ingredient  to  enabling  scalability  for 
the  CTM. 


4  CTM  PROTOTYPE 

Before  discussing  in  detail  how  the  CTM  prototype  will  achieve  program  goals,  it  is  useful  to  introduce 
the  features  of  the  proposed  module.  This  section  will  highlight  important  elements  of  the  design, 
including  a  brief  description  of  subsystems  in  the  proposed  module  and  key  features.  A  block  diagram  of 
the  CTM  is  shown  in  Figure  2.  This  section  provides  a  brief  overview  of  subsystems  in  the  proposed 
module  and  key  features. 
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4.1  Time  Engine  -  GPS-Disciplined  Rb  Oscillator 

At  its  core,  the  CTM  is  a  time  server  that  requires  a  traceable  connection  to  the  desired  time  reference  (in 
this  case,  UTC-USNO).  For  mobile  operations,  a  GPS  receiver  is  the  most  practical  link  to  UTC.  This 
program  will  rely  on  an  off-board  IS-GPS-153  compliant  GPS  receiver.  The  Time  Engine  module 
accepts  GPS/UTC  time  from  the  Ground-Based  GPS  Receiver  Application  Module  (GB-GRAM)  and 
disciplines  its  Rb-oscillator  time  and  frequency  to  provide  holdover  capability.  This  extends  precision 
timing  to  areas  of  operation  where  GPS  is  denied  or  degraded.  Looking  at  this  feature  another  way,  a 
disciplined  Rb  oscillator  provides  the  first  level  of  reliability  to  time  maintenance  capability. 

4.2  Holdover  Oscillator 

To  implement  the  holdover  Rb  oscillator,  CTM  includes  an  integrated  Chip  Scale  Atomic  Clock  (CSAC) 
0.  CSAC  provides  Rb  atomic  clock  performance,  requiring  only  100  mW  of  power.  This  helps  achieve 
the  overall  objective  of  low-power  operation  with  atomic  clock  holdover  performance.  Figure  3  shows 
the  CSAC  installed  on  the  CTM  Phase  II  Time  Engine  breadboard. 


GPS  Ant 


Figure  2.  CTM  block  diagram. 
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Figure  3.  CTM  Phase  II  Time  Engine  breadboard. 


4.3  Network  Module 


Networking  capability  is  a  fundamental  feature  of  the  CTM.  The  CTM  can  have  0,  1,  or  2  physical 
Ethernet  ports  installed.  Each  CTM  has  the  capability  to  operate  as  an  IEEE-1588  Grand  Master, 
Alternate  Master,  or  Ordinary  Clock  0.  Networking  on  the  CTM  can  be  used  to  both  serve  and  receive 
time,  as  the  situation  demands.  The  second  network  port  allows  the  CTM  to  operate  despite  the  failure  of 
any  one  network  link.  This  works  best  when  the  ports  are  connected  through  different  Ethernet  switches. 

4.4  Legacy  Time  Distribution 

The  CTM  is  a  forward-looking  design,  but  must  accommodate  legacy  equipment.  To  that  end,  each  CTM 
has  dedicated  legacy  ports  that  supply  time  via  AN/PSN-11  TOD  port  (variant  of  HaveQuick),  NMEA- 
0183,  and  IRIG.  Each  CTM  in  the  system  cluster  will  be  able  to  service  local  time  users  with  these  ports. 

4.5  CTM  Key  Features  -  Overview 

•  GPS  Receiver  (GB-GRAM)  is  the  primary  time  reference 

•  Disciplined  CSAC  to  support  holdover  time  for  GPS-denied  environments 

•  Network  Time  via  PTP  (IEEE- 1588  v2) 

•  Legacy  time  distribution 

•  Low  power  design 
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5  SYSTEM  CONSIDERATIONS 

5.1  Time  Transfer  Accuracy 

The  key  function  of  the  CTM  is  to  distribute  time  to  client  instruments.  To  deliver  accurate  time,  it  is 
important  to  consider  the  inherent  accuracy  of  the  technique  used  to  communicate  time  to  the  client. 
Error!  Reference  source  not  found,  lists  the  time  transfer  mechanisms  available  with  the  CTM. 
Precision  Time  Protocol  (PTP),  in  constrained  network  configurations,  can  achieve  very  accurate  time 
transfers  (sub-ns  performance  have  been  reported  [2-4])  in  a  very  economical  transport  medium  (Ethernet 
cable).  In  practice,  to  achieve  these  high  levels  of  performance,  system  integrators  must  control  network 
elements  and  cabling.  For  the  envisioned  applications  (Error!  Reference  source  not  found.),  this 
controlled  type  of  system  design  is  feasible.  The  following  lists  some  of  the  network  implementation 
issues  that  can  impact  PTP  performance. 

1.  Time-stamping  Implementation  -  CTM  will  implement  precise  hardware  time-stamping  of  PTP 
packets,  but  Slaves  can  implement  sub-optimum  designs  and  still  claim  compliance  to  the  standard. 
Fortunately,  this  does  not  negatively  impact  other  users. 

2.  COTS  Network  Switches  and  Routers  -  By  inserting  a  non-1588  compliant  switch,  PTP  performance 
can  be  severely  degraded,  due  to  unpredictable  packet  queuing  delays. 

3.  Traffic  Fevels  -  Communications  activity  on  a  shared  network  can  impact  PTP  performance.  While  a 
fully  realized  IEEE- 1588  network  is  fairly  resilient  to  degradation  by  superfluous  network  traffic  0, 
there  is  some  modest  falloff  that  must  be  quantified.  For  critical  applications  where  PTP  must  be 
optimized,  separate  network  elements  are  an  acceptable  solution  (keep  PTP  off  the  high  traffic 
network). 

4.  Cabling  and  Interconnect  -  To  achieve  the  highest  level  of  performance,  cabling  issues  must  be 
considered  0. 

One  of  the  activities  planned  for  CTM  Phase  111  is  to  quantify  the  time  transfer  performance  of  PTP  in 
small  networks,  such  as  the  ones  sketched  in  Figure  4,  5,  &  6. 

5.2  Power  Consumption 

Reducing  system  power  consumption  is  an  explicit  goal  of  the  CTM  program.  Replacing  a  heterogeneous 
mix  of  custom  timing  systems  by  a  single  CTM-based  server  is  one  method  of  achieving  this  goal. 
However,  to  maintain  this  advantage,  the  CTM  must  be  inherently  low  power.  The  CTM  uses  techniques 
and  parts  selection  to  keep  power  consumption  low.  The  breadboard  CTM  Time  Engine  requires  less 
than  3  watts,  including  the  CSAC  holdover  oscillator.  Further  improvements  are  possible  as  the  prototype 
design  is  clarified. 
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Table  2.  Time  transfer  techniques. 


Network  Standards 

Point-to-Point  Legacy  Standards 

IEEE- 1588 
(PTP) 

NTP 

NMEA-0183 

IRIG 

PPS 

peak  time 
transfer 
error  (typ) 

1-100  ns 

100  ms 

-1  ms 

1-10  us 

<  Ins 

Physical 

IEE-1588 

compliant 

Ethernet 

Standard 

Ethernet 

RS-232, 

RS-422 

RF  Coax 

Digital  Logic 

Style 

Master/ 

slave(s) 

Client(s)  / 
Server 

Master/ 

slave 

Master/ 

slave 

Master/ 

slave 

Automatic 

latency 

correction 

Yes 

Yes 

No 

No 

No 

Notes 

No 

Time  of  Day 

5.2.1  Battery-Backed  Holdover  Oscillator 

The  CSAC  oscillator  requires  only  100  mW  of  power.  It  includes  an  internal  1  pps  subsystem  that  can  be 
used  to  store  and  recover  time.  Therefore,  the  CSAC  can  support  a  “warm-restart”  mode  of  the  CTM  that 
requires  only  100  mW  during  the  low-power  holdover  period.  This  mode  is  within  range  of  battery 
powered  operation. 

For  example,  an  ordinary  commercial  12  V  lead-acid  car  battery  has  about  500  watt-hours  of  capacity. 
Thus,  a  CSAC  could  remain  powered  for  -200  days  from  that  battery.  As  an  added  advantage,  a  CSAC 
emerging  from  a  warm-start  condition  is  not  subject  to  the  normal  cold-start  drift  effects  that  degrade  the 
performance  of  all  high-precision  quartz  oscillators.  Specified  aging  performance  is  available 
immediately. 

5.3  Reliability,  Redundancy,  Fault  Tolerance,  and  Networking 

Within  industry  publications  on  Ethernet  networking,  the  subject  of  redundancy,  fault  tolerance,  and 
reality  represents  a  broad  and  active  area.  The  IEEE- 1588  protocols  are  particularly  relevant  to  this 
discussion.  While  even  a  brief  overview  of  this  topic  is  well  beyond  the  scope  of  a  single  paper,  it  is 
worth  examining  some  relevant  techniques  that  are  particularly  well  suited  to  the  target  applications 
planned  for  the  CTM.  In  addition,  because  many  of  the  1588  protocols  have  broad  commercial 
applicability,  the  robust  performance  that  is  derived  from  an  enormous  installed  base  is  evident. 

5.3.1  Best  Master  Clock  Algorithm 

The  Best  Master  Clock  (BMC)  is  an  IEEE-1588  standard  mechanism  for  dynamic  selection  of  a  Master 
Clocks  used  by  network  Slave  Clocks.  It  provides  fault  tolerance  because  a  CTM  that  is  a  Master  or  a 
CTM  Ordinary  Clock  will  start  sending  announce  messages  and  sync  messages  if  they  don’t  hear  from  a 
better  Master.  So  if  the  original  Best  Master  stops  sending  messages  for  any  reason,  another  Clock  will 
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automatically  take  over.  The  BMC  provides  a  deterministic  algorithm  for  dynamically  defining  which 
CTM  will  be  source  time  to  the  network.  Configuration  parameters  allow  Master  succession  to  be 
defined  by  a  system  integrator,  or  happen  automatically  as  a  function  of  each  devices  broadcast  “clock 
quality.” 

5.3.2  Alternate  Master  Clock 

If  an  IEEE-1588  Grandmaster  fails  or  degrades  substantially,  the  BMC  will  automatically  trigger  the 
transition  of  Slave  Clocks  to  the  next  best  Clock  (in  this  case,  presumed  to  be  another  CTM).  While  this 
transition  is  automatic,  there  is  a  transition  period  when  the  Slaves  resynchronize  themselves  to  a  new 
CTM  Grandmaster.  By  implementing  an  “Alternate”  Master,  another  CTM  can  operate  as  a  “hot-spare,” 
which  will  speed  transition  and  help  maintain  accurate  time  distribution.  The  Alternate  Master  function 
can  also  be  used  by  Slaves  to  compare  one  Master  to  another  and  implement  a  voting  or  ensemble 
synchronization  schemes.  This  allows  Slaves  to  stay  on  time  even  if  the  Best  Master  is  drifting  off  time, 
but  reporting  itself  as  healthy. 

5.3.3  PRP 

A  number  of  techniques  exist  to  address  cable  failures  in  fault-tolerant  network  design.  Parallel 
Redundancy  Protocol  (PRP)  makes  use  of  two  independent  Ethernet  networks.  Frames  are  replicated  by 
the  sending  node  and  transmitted  over  both  networks.  This  scheme  works  without  explicit 
reconfiguration  and  switchover  and,  therefore,  does  not  show  a  period  of  unavailability.  It  can  provide  a 
high  level  of  fault  tolerance  to  cabling  failures  and  is  the  driver  for  the  CTM  optional  support  of  two 
Ethernet  ports.  Adapting  IEEE  1588  to  PRP  and  other  redundant  Ethernet  protocols  is  currently  an  area 
of  active  research  within  the  industrial  automation  and  power  utility  industries. 

5.3.4  STP  and  RSTP 

The  Spanning  Tree  Protocol  (STP)  and  the  Rapid  Spanning  Tree  Protocol  (RSTP)  are  two  techniques  that 
provide  fault  tolerance  without  a  complete  set  of  redundant  Ethernet  connections  and  cabling.  The  idea  is 
to  use  alternate  connection  paths  either  by  a  ring  or  tree  topology. 

5.4  Representative  CTM-Based  Systems 

The  following  section  describes  selective  system  configurations  of  the  CTM.  This  is  not  a  comprehensive 
list,  but  shows  ways  the  CTMs  can  be  applied  to  achieve  different  requirements. 

5.4.1  Fully  Redundant  CTMs 

Figure  4  shows  a  case  where  two  CTMs  on  a  platform  are  directly  connected  via  network  crossover  cable. 
Each  can  operate  independently  as  a  PTP  Grandmaster  clock.  The  other  CTM  will  automatically 
configure  itself  as  an  Ordinary  Clock  (or  an  Alternate  Master).  This  simple  arrangement  provides  a 
substantial  amount  of  fault  tolerance.  The  loss  of  either  GPS  antenna  and/or  GPS  receiver  would  trigger 
the  BMC  algorithm  and  switch  the  network’s  Grandmaster.  Using  PTP,  the  legacy  ports  will  continue  to 
provide  accurate  time  on  BOTH  units,  because  a  single  GPS  failure  would  not  prevent  time  transfers  from 
the  fully-operational  CTM. 
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Figure  4.  Fully  redundant  CTMs. 


5.4.2  Remote  CTM  (Time  Repeater) 

Figure  5  shows  another  system  topology  with  two  CTMs.  As  before,  both  CTMs  can  supply  time  to 
legacy  users  from  their  respective  ports.  But  in  this  case,  one  CTM  will  NOT  have  access  to  a  GB- 
GRAM  and,  therefore,  cannot  operate  as  a  redundant  Grandmaster.  However,  it  can  receive  time  via  its 
network  connection  and,  therefore,  can  supply  precision  time  to  its  legacy  ports.  Thus,  the  CTM  becomes 
a  legacy  port  “repeater”  which  extends  time  services  using  Ethernet.  Furthermore,  the  remote  CTM  still 
has  holdover  capabilities  and  can  continue  supplying  precision  (holdover)  time  for  some  period  after  a 
cable  failure. 
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Figure  5.  Remote  CTM. 
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5.4.3  Fully  Redundant  CTMs  with  Network  Time  Distribution 

The  next  system  shows  a  medium-sized  deployment  with  two  CTM  masters  and  two  network  time  users. 
This  provides  redundancy  using  two  CTMs  and  shows  instruments  getting  precision  time  from  the 
network. 


GPS  Ant  GPS  Ant 


Figure  6.  Full  network  time  system. 


5.5  System  Field  Maintenance 

The  IEEE-1588-based  implementation  provides  another  advantage  to  system  developers.  In  most  cases,  it 
configures  and  optimizes  itself.  The  Best-Master  algorithm  will  automatically  accommodate  multiple 
CTMs.  Using  the  power  of  networking  and  existing  IEEE-1588  standard  features,  the  system  will  control 
and  optimize  itself  without  user  intervention. 

5.6  IEEE-1588  APPLIANCE 

The  first  generation  of  systems  that  use  the  CTM  will  undoubtedly  rely  on  legacy  ports  for  time 
distribution.  Also,  as  shown  in  Figure  4,  the  Ethernet  port  can  be  used  for  pure  CTM-to-CTM 
communications.  However,  the  advantages  of  using  network-based  time  distribution  will  eventually  lead 
instrument  developers  towards  IEEE-1588  for  time  distribution.  To  jumpstart  this  effort  and  ensure 
consistent  performance,  the  development  of  a  small  embeddable  module  that  acts  as  a  simple  Slave  Clock 
has  great  potential  for  CTM  adoption.  This  module  (an  “IEEE-1588  Appliance”)  would  implement  the 
necessary  packet  hardware  time-stamping  and  provide  the  instrument  designer  Time-of-Day  (TOD)  and 
Pulse  per  Second  (PPS).  Unlike  the  full  CTM,  an  IEEE-1588  appliance  would  always  be  a  Slave  Clock 
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and  holdover  is  optional  (this  capability  is  supplied  by  the  CTM-based  Grandmaster).  In  low-power 
instrument  packages,  the  addition  of  Power  over  Ethernet  (PoE)  could  simplify  system  integration  effort 
using  industry  standard  techniques. 


6  CONCLUSIONS 

The  CTM  was  conceived  as  a  core  module  with  the  capability  to  support  a  wide  range  of  mobile 
platforms  with  a  precision  time  resource.  The  core  timing  engine  uses  a  GPS -disciplined  CSAC  for  ultra- 
low  power  consumption  and  Rb  oscillator  performance.  By  combining  a  solid  time  maintenance  engine 
with  a  fully  compliant  1588  Master  Clock  module,  it  is  possible  to  support  a  wide  range  of  fault -tolerant 
and  redundant  timing  system  implementations.  Furthermore,  a  network-centric  approach  using  IEEE- 
1588  provides  self  configuring  (and  reconfigurable)  operations  that  minimize  system  maintenance  issues. 
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